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ABSTRACT 



Automated data processing for non-tactical applications afloat was first implemented 
on large platforms with the SNAP I system. This system provided excellent inventory 
management, financial and accounting service in the punch card and magnetic tape 
environment in which it was introduced. Subsequent modifications have been made to 
take advantage of changing technologies and increased user expectations. 

Automated data processing on smaller platforms was implemented with the SNAP 
II program. While serving many of the same functions this implementation was designed 
separately and for a different user group. 

The SMMS program discussed here in a case format was an attempt to consolidate 
and enhance the two SNAP programs. 
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I. INTRODUCTION 



A. THE TOPIC 

This thesis will point up some of the many and often conflicting 
influences that impact on management information system and 
programming decisions in the naval environment. These trends and 
pressures are presented in a case study setting with enough background 
material to allow the reader to grasp the complexity of the situation. 
Rather than espousing one right answer the reader should come away with 
personal solutions that will aide them in confronting similar projects. 

B. BACKGROUND 

The first automated non-tactical systems to go to sea were designed to 
provide supply and financial functions for auxiliary ships. These systems 
kept track of material carried on board but belonging to an ashore activity. 
They also provided record keeping for the ship’s own financial and supply 
requirements. This first system was called SNAP I for Shipboard Non- 
tactical Automated Data Processing. The system ran on a mainframe 
computer in batch processing mode. The initial system used punch cards 
and reports and financial data tended to be about a week behind the actual 
transactions. Subsequent upgrades in hardware and software have moved 
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some ships and shore stations to the current version known as Shipboard 
Uniform Automated Data Processing System-Real Time (SUADPS RT)(PRC, 
1991) or SNAP I release three. The real time in the name implies that the 
processing is almost instantaneous after the transaction is input to the 
system. Although some might argue that the system only simulates a real 
time mode, since transactions update copies of data files on a real time 
basis. Actual updates of the master financial and inventory files are 
modified in batch updates on a daily basis. This situation is somewhat 
analogous to a deposit in an automatic teller machine where your balance 
is shown with the deposit added but a lower balance will be shown if the 
machine is immediately rechecked. The new higher balance will only show 
again after the deposit envelope has been opened and the master record 
updated. 

Subsequent to SNAP I, SNAP II was designed to provide the financial 
and inventory record keeping portion of SNAP I that applied to smaller 
ships onboard spares inventory and consumable items. In SNAP I the 
similar section was called own ships use. SNAP II was designed for ships 
using micro or mini computer hardware, afloat accounting and far fewer 
staff people to run it. The financial section of the small ships system was 
simpler since these ships were only required to maintain internal budgets, 



2 



operating target (OPTAR) logs and end use stock records; and did not 
require accounts for wholesale and retail stocks and costs for tended vessels. 
These financial record systems also represent simplified afloat accounting 
rather than the more complex shore station system used in SNAP I. This 
more complex shore accounting used in the SNAP I systems stems from the 
fact that the majority of the inventory controlled actually belongs to the 
Navy Stock Fund and is not the property of the ship. 

The two SNAP systems perform many of the same functions with 
regard to internal ships supply functions. Despite the seeming functional 
similarities, each system was developed separately for different hardware 
configurations. Designing to these hardware differences yielded systems 
with little in common with regard to how they "look and feel" from the 
human interaction standpoint. For example, the Storekeeper (SK) rating 
has had two sets of questions in the advancement exams representing how 
functions are symbolized and performed on the two systems. Of concern 
from a manpower assignment perspective is that a junior SK is much more 
likely to have hands-on training in the SNAP II system but he or she is apt 
to be subsequently asked to supervise on a SNAP I afloat platform or shore 
activity without any real background. This requirement for two separate 
training pipelines has been a motivator for standardizing as many functions 
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as possible between the two systems. The possible cost savings from 
reducing the number of systems being maintained is also a motivator in 
funding constrained environment of the early 1990s. 

The differences between the two SNAP systems are reflected in the 
parallel organizational structures maintained to supervise them. All 
surface and submarine type commanders maintain separate internal 
organizations to provide guidance to supervised activities using each 
system. The experience sought in staff and the guidance given to 
subordinate activities varies widely between SNAP I and SNAP II 
organizations. 



C. SOURCES OF INFORMATION 

Due to the lack of literature in the area of SNAP I and SNAP II 
consolidation, the majority of sources of information were personal 
interviews conducted at Navy Management System Support Office 
(NAVMASSO) in June of 1991 and follow-up phone calls to NAVMASSO 
and Naval Supply Systems Command Fleet Support Division (NAVSUP 
04D). Further input was obtained from vendor product documentation, 
articles in current computer periodicals, Navy notices and instruction and 
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survey data collected from Type Commanders in the Atlantic and Pacific 
fleets and the Marine Corps by NAVSUP in the fall of 1991. 
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II. CASE METHODOLOGY 



A. CASE STUDY FOR RESEARCH 

A case study "investigates a contemporary phenomenon within its real 
life context; when the boundaries between phenomenon and context are not 
clearly evident; and multiple sources of evidence are used. "(Yin, 1989) 

The appropriate subject matter for a good case may be a cutting edge 
problem not yet faced by many business leaders. Most cases should center 
on common-place problems routinely faced by managers. (Culliton, n.d.) 

A case study attempts to capture a snapshot of an organizational 
situation as it unfolds, without imposing experimental controls. In a case, 
an observer attempts to see the invisible forces acting in and on an 
organization through the observable actions of individuals. (Lee, 1986) 

B. TYPES OF CASES 

Culliton (1973) groups cases into three general types based on the 
degree of problem specificity. The first and generally the shortest is the 
specific problem case. These cases are quite specific about the nature of the 
problem and who has the problem. The second, longer type is the 
diagnostic case. In these cases fact that someone has a problem is less clear 
cut. The specifying of the problem and the person or persons having the 
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problem is more open to interpretation than in the specific problem case. 
The third type and usually longest is the appraisal case. In this type 
readers may clearly disagree on whether there is a problem or not. The 
topic of discussion will include the alternative of not changing anything. 
"Prognosis may be more important than diagnosis." 

Bennett(Davis ,n.d.) takes a somewhat more restrictive view on types 
of cases. His two categories of cases are both closely related to the specific 
problem case. The first type is the issue case in which the author presents 
a problem and the reader develops scenarios to solve it. The second type is 
the appraisal case where the author describes a management solution used 
and the reader critics the solution. 

Both authors agree that the time span of a case is specific. The span 
covered should be decided and events happening after the period covered 
should be excluded. Only in such a limitation can a realistic problem 
solving situation be created. 

C. ADVANTAGES OF TEACHING CASES 

Proponents of the case study method of teaching feel that the quality 
and quantity of material retained by the student is larger when the case 
method is used. The advantages are attributed to information fallout 



7 



phenomena. The fallout results from the students seeing an immediate 
application of and use for the information received. (Culliton, 1973) 

The use of qualitative data and descriptions can be an advantage in 
the case study method. Descriptions of situations and context can give the 
reader a greater perception of the nature of real life decision making. Such 
rich descriptions can stir the readers imagination more readily than bare 
numerical data.(Miles, 1984) 

A case study method teaches the student that there is often more than 
one viable alternative.(Pascale, 1973) The habits of diagnosing problems, 
analyzing and evaluating alternatives and developing possible responses 
have value in their own right/Harvey, 1988) The case method can also 
illustrate the influence of political power on decision makingXLee, 1986) 

Skills learned in dealing with the case methodology can be particularly 
valuable in the information systems arena. The rapid rate of technological 
change and innovation in the information system area have a continuing 
impact on organization and management. The deductive skill and insights 
gained through the use of cases can provide excellent preparation for 
change. (Benbasat, 1987) 



8 



D. DISADVANTAGES OF CASE STUDIES 



The use of qualitative data can be a disadvantage of case studies 
particularly when they are used for research. Qualitative data in case 
studies tends to be very difficult for a follow on researcher to duplicate and 
thus verify. (Lee, 1986) Standardized methods of analysis for qualitative 
data are lacking.(Miles, 1984) 

Data collection methods for case studies can be time-consuming and 
require extensive documentation. Even if abbreviated methods of data 
collection are use, production of a quality case study is a difficult endeavor. 
No proven criteria have been developed to determine if an author has the 
requisite skills to write a quality case study. Yet critics argue that results 
obtained can only be generalized with extreme care. (Yin, 1989) 
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III. NON-TACTICAL ADP ENVIRONMENT 



A. INTRODUCTION 

Traditionally the Navy has separated the automated data processing 
(ADP) function into two categories, tactical and non-tactical. The Warner 
amendment to the Brooks act and the paperwork reduction reauthorization 
act of 1986 both drew a distinction in the equipment covered by the law 
based on application within the Department of Defense. (McDonough, 1990) 
Generally ADP applications that were of a tactical nature or part of a 
weapon system were exempted and thus subject to fewer regulatory 
guidelines. On the non-tactical side, programs and applications are subject 
to a different set of standards and require more extensive justification along 
cost benefit lines. 

The net effect of the traditional separation was to have distinct 
hardware and software developments in the two areas. The people who 
developed the two types of systems worked at different activities and 
seemed to have little in common. These separations were heightened by the 
fact that tactical systems tended to be organic to pieces of hardware and to 
be either real time or interactive in nature. Non-tactical systems on the 
other hand originally tended to be based on large mainframe operations and 
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were batch in nature or else they were stand alone and used largely for 
word processing. 

B. ADP DISTINCTIONS DIMINISHING 

In a speech to the September 1991 Navy micro computer conference, 
the Navy’s senior IRM official, Gerald Cann, addressed current trends in 
Navy ADP. (Green, 1991) He feels that the old differences between tactical 
and non-tactical hardware and software are diminishing. In parallel with 
this trend, the separation in the procurement methods used is also 
decreasing. 

Custom made software for use with tactical systems is being 
supplanted by off-the-shelf packages. This trend should allow the 
procurement system to reduce or eliminate the distinctions which have 
confused procurement issues dealing with tactical and non-tactical 
technology. Cann also strongly believes that the acquisition cycle for 
computers should be reduced to an 18 month turn around. (Green, 1991) 

Robert Green, director of information resources interoperability for the 
Navy’s Information Technology Acquisition Center gives further insight into 
the changes taking place. In 1991, the data processing systems in ships 
tend to support the separate activities and the groups supporting those 
activities. (Robb, 1991) If a part fails in a tactical system the request for a 
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spare part would first go to the division maintenance people for a check of 
the ready service spares bins. If it is not found the search would be 
extended to supply department stocks. The request would have to be 
entered into a separate supply system. Even if the part is found onboard, 
the maintenance action performed must be entered into a separate 
maintenance tracking system. If the part is not found and the equipment 
is non-functional, a casualty reporting system will become involved. Mr 
Green sees an integrated environment coming where the failure of the part 
and the required responses can be largely automated without repeated 
intervention in the form of duplicate data entry into parallel systems. (Robb, 
1991) 

The integration of tactical and non-tactical networks is demanding a 
new level of cooperation from two systems commands, NAVSEA (Naval Sea 
Systems Command) and SPAWAR (Space and Naval Warfare Systems 
Command). NAVSEA previously dealt mainly with problems internal to the 
ship while SPAWAR’s main emphasis was on problems external to the 
ship.(Robb, 1991) 

Yet another perspective can be gained by looking at the changes taking 
place in the way the Navy buys ADP equipment. Captain McQueen, 
commanding officer of Information Technology Acquisition Center (ITAC) 
recently gave his perspective. (Robb, 1991) The trend in industry is to lower 
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the barriers between telecommunications and computers. It would be 
difficult to say whether the move toward the picture phone and other 
broadband communications or the trend toward multimedia and distributed 
computing is the main driver but distinctions are blurring. ITAC will be 
buying both base telecommunications systems and information processing 
systems. (Robb, 1991) 

The ITAC staff will be buying the $40 million Tactical Advanced 
Computer (TAC-3) procurement as well as the SNAP-3 procurement, now 
in its early planning stages(Robb, 1991). 

C. PROGRAMMING LANGUAGES 

In 1987 the Defense Department issued a Directive replacing its 
earlier 1976 Instruction on Higher Order Languages (HOL) in the 
Department of Defense. The directive provides policy guideline for 
computer programming languages used in both development and support 
of DoD software(DoD 3405.1, 1987). 

As in personal computers and other non-government business 
applications there is a tradeoff between changing to the latest tool and the 
large capital investment in an already acquired inventory of software. The 
directive attempts to balance these opposing forces while limiting the 
overall number of HOLs that are allowed. The main thrust of the limitation 
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is to support the goal of transition to the use of Ada(MIL-STD-1815A, 1983) 
for Department of Defense software development(DoD 3405.1, 1987). 

In support of the transition goal a list of the only acceptable HOLs is 
included. These authorized HOLs can be used to complete major projects 
that have passed milestone II(DoD 5000.1, 1986). In these and other 
completed projects the other languages can be used subsequently for 
software maintenance but not for major upgrades. Other authorized HOLs 
may also be authorized for projects w T here they have a demonstrable 
advantage over Ada(DoD 3405.1, 1987). This advantage should be in terms 
of life-cycle cost savings and fulfillment of system requirements. 

The Directive states preference can be given to off-the-shelf software 
and advanced software technology. However, due consideration must have 
been given to the future impact on competition for software and 
hardware(DoD 3405.1, 1987). Use of the new technology must not set up 
future sole source buy situations unfavorable to the government. 

More recent events seem to reinforce the stand taken by DoD on Ada. 
In 1991 Paul Strassmann, director of defense information, asked the DOD’s 
Information Technology Policy Board to evaluate Ada and C++ which is not 
on the list of approved HOLs(DoD 3405.1,1987) and recommend whether 
DOD should use C++ for some projects. Five contractors prepared reports 
with their efforts coordinated by Lloyd K. Mosemann, deputy assistant 
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secretary of the Air Force for communications, computers and 
logistics(Schwartz, 1991). No significant reasons were found to "waive the 
Ada requirement" in favor of C++(Schwartz, 1991). One of the reporting 
contractors TRW Inc. found Ada’s score on a range of software engineering 
issues to be over 20% higher than the score tabulated for C++. This same 
report recommended that waivers for the use of C++ at least through 1993 
only be granted for conversion of software originally written in C(Schwartz, 
1991). 

D. TRENDS 

The overall trend in shipboard computing is toward consolidation of 
systems. The smaller number of hardware and software systems that need 
to be supported allows economies in staffing, lower software maintenance 
costs, and fewer repair part requirements. 

DoD is attempting to consolidate and standardize programming 
languages. Streamlining the programming of new systems by reuse of 
previously developed code should save money. Ada was developed with 
reuse of code segments as a basic premise. The use of Ada is now being 
expanded from tactical applications into all shipboard applications. 
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IV. SNAP CONFIGURATION MANAGEMENT 



A. OBJECTIVES 

The stated objectives of SNAP configuration management were: 

a. To assist SNAP program management in achieving the most cost- 
effective performance, operational efficiency, implementation schedule, 
logistic support and readiness. 

b. To attain maximum efficiency in the management of engineering 
changes. 

c. To achieve the following goals at a system level: 

(1) To ensure that verified configuration technical 
documentation is available when needed. 

(2) To maintain hardware and software standardization and 
compatibility. 

(3) To ensure that total performance, costs, and schedule impact 
of change proposals, deviations, and waivers are known at the time of 
approval. 

(4) To ensure that all hardware and software configurations are 
defined and that pertinent physical and functional interfaces between 
systems, equipments, and software programs are documented and 
controlled.(SPAWAK 4130.12, 1986) 



B. ORGANIZATION 

The same instruction established a system of boards and committees 
to carry out these stated objectivesfSPAWAR. 4130.12, 1986). The SNAP 
Joint Configuration Control Boards (JCCBs) were chaired by the SPAWAR 
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SNAP Program Directorate or designee, who had ultimate authority for it’s 
decisions. The JCCBs also have permanent members representing the 
Commander NAVSEASYSCOM and Commanding Officer Navy 
Management System Support Office (NAVMASSO). The SNAP I JCCB had 
additional permanent members representing Commander, Naval Air 
Systems Command (NAVAIR) to interface on matters relating to Naval Air 
Logistics Command Management Information System (NALCOMIS), 
Commander, Naval Data Automation Command (NAVDAC) for Type 
Commander Headquarters Automated Information System (THAIS) 
matters, and a non-voting member from the Automated Data Processing 
Selection Office (ADPSO) to advise on SNAP I contract matters. The 
JCCBs further had Ad Hoc members representing SNAP Functional 
Managers, Chief of Naval Education and Training (CNET), and the Fleet 
Commanders in Chief. The SNAP I JCCB also had an Ad Hoc member 
representing the Commandant, Marine Corps. 

Subordinate to the JCCB were the SNAP Hardware Configuration 
Control Committees (HCCCs). The Chairman of these committees and final 
arbiter on any matters not requiring referral to the JCCBs was Commander 
NAVSEASYSCOM or his designee. SPAWAR as the SNAP program 
manager was a permanent member of the HCCCs and had the authority to 
refer proposals to the JCCBs for decision. The other permanent members 
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were representatives of: NAVMASSO fleet Central Design Agency and 
Naval Sea Combat Systems Engineering Station 
(NAVSEACOMBATSYSENGSTA) as In Service Engineering Activity 
(ISEA). The SNAP I HCCC also had permanent members representing 
NAVAIR the NALCOMIS Program Manager and a non-voting 
representative of ADPSO to answer questions on the AN/XJYK-65 hardware 
contract. The Ad Hoc members of the HCCCs were representatives of at 
least the following: Naval Supply Systems Command (NAVSUP) to insure 
proper coordination with its inventory control points, CNET as SNAP 
training interface and Fleet Commanders in Chief as user representatives. 
SNAP I HCCC also had Ad Hoc members representing the Commandant, 
Marine Corps as a user and NAVDAC for THAIS interface. 

Also subordinate to the JCCBs were the SNAP Software Configuration 
Control Committees (SCCCs). The Chairman of these committees and final 
arbiter on any matters not requiring referral to the JCCBs was 
Commanding Officer Navy Management Support Office (NAVMASSO) or 
his designee. SPAWAR as the SNAP program manager was a permanent 
member of the SCCCs and again had authority to refer proposals to the 
JCCBs for decision. In a swapping of roles from the HCCCs another 
permanent member was a representative of NAVSEA to evaluate the 
potential impacts of changes on hardware .and firmware. 
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NAVSEACOMBATSYSENGSTA as ISEA was again a permanent member. 
The SNAP I SCCC also had permanent members representing NAVAIR the 
NALCOMIS Program Manager, Navy Regional Data Automation Center 
Norfolk representing THAIS issues and a non-voting representative of 
ADPSO to answer questions on SNAP I contract issues. The Ad Hoc 
members of the SCCCs were representatives of at least the following: 
Commander Naval Supply Systems Command (COMNAVSUPSYSCOM) as 
SNAP Functional Manager, CNET as SNAP training interface and Fleet 
Commanders in Chief as user representatives. SNAP I SCCC also had Ad 
Hoc members representing the Commandant, Marine Corps as a user. 

C. RESPONSIBILITIES 

The JCCBs were responsible for overall policy guidance on 
prioritization of change actions, reporting requirements, and general 
management of the program. They were also responsible for announcing 
their meetings at least 45 days in advance to allow the subordinate 
committees to publish and distribute agenda items 30 days before the 
meetings. Issues requiring new funding, schedule changes or not limited 
to Hardware or Software areas as well as after the fact reviews of the 
decisions of the SCCCs and the HCCCs also were the JCCBs responsibility. 
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The HCCCs were responsible for hardware and firmware configuration 
control, record keeping, auditing of installations and monitoring of 
contractor configuration management. They also had to evaluate integrated 
logistics support elements and funding levels before implementing 
configuration changes. Finally they had to organize and research and 
provide recommendations for issues that were to be referred to the JCCBs 
for resolution. 

The SCCCs’ responsibilities included deciding all software change 
issues that don’t effect funding levels, scheduling or hardware. They also 
develop procedures, conduct audits, perform configuration status accounting 
and historical record keeping. Finally they develop schedules and priorities 
for their area of responsibility. 
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V. SNAP MATERIAL MANAGEMENT SYSTEM CASE STUDY 



A. CASE SITUATION 1 

In August 1989 SMMS project manager Margaret Winston at 
NAVMASSO in Norfolk Virginia assigned Bobby Jenkins and three other 
analysts to start data modeling and analysis of the SNAP Material 
Management System (SMMS) project. This initial effort was centered 
around the Information Engineering Systems Corporation (IESC) 
methodology and was assisted by one of a series of rotating contractor 
personnel. 

In keeping with the IESC format, emphasis was placed on data not 
procedures and business knowledge rather than technology. The IESC 
CASE tool focuses on modeling the business process using 
Finkelstein’s(Keyes, 1992) method of breaking activities down into fourth 
and fifth business normal form. The data is divided and then grouped into 
entities which represent a table in a relational data base in fifth normal 
form. All possible relations between data elements are defined in one of 
these tables. This separation of data into fifth normal form permits a 

x This is a preliminary version of a case study which has not yet 
been approved for public release. It is not for republication or 
quotation. 
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segregation of business detail into objects. These objects are intended to 
group data and the associated relationships and interactions between 
dataCKeyes, 1992). In support of this task the IESC CASE tool generates 
numerous reports including Entity Report, Entity Purpose Report, 
Association Report, Subject data base implementation priorities, and 
Attribute Report. 

Over the ten months of the modeling effort, Margaret’s group defined 
and categorized increasingly complex entity models until three hundred and 
fifty eight active entities had been defined. The condensed version of the 
first four reports showing only active entities had grown to one hundred and 
seventy pages by mid 1991. 

In the twelve months of the IESC contract, twelve different consultants 
were assigned. One of the first IESC consultants with some non-specified 
informal input from senior officers in the Washington arena, initially 
identified the following twenty five business functional areas. 

• Transaction Access 

• Organization Identification 

• Organization Categorization 

• Address 

• Person 

• Skill 
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Item Identification 



• Contract 

• Customer Need 

• Performance Monitoring 

• Priority Management 

• Requisition Status 

• Supply Requirement 

• Supply Requisition 

• Item Handling 

• Location 

• Requisition Receipt 

• Item Configuration 

• Organization Allowance Level 

• Organization Item Management 

• Inventory Physical Distribution 

• Item Management 

• Fund Accounting 

• Fund Authorization 

• Fleet Freight (NAVMASSO, 1991) 

At a more tactical level the business functional areas were grouped 
into four functional areas and assigned to the four analysts at NAVMASSO 
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for development of entities within areas. Financial was first, consolidating 
accounting practices under ashore and afloat rules. Second were security 
concerns. Requirements and inventory control were third and fourth 
respectively. Next, end user input was solicited from seven commands, 
each one level above actual operational units. Each of these commanders 
controlled operational units using either SNAP I or SNAP II. Group 
meetings were scheduled and held on both coasts to identify the basic 
entities which in the IESC scheme would be the low level objects and the 
logic that acts on those objects. In addition to basic entities, the meetings 
were to develop attributes and relationships of entities as well as edit rules 
and display input items. Between meetings, the NAVMASSO analysts and 
IESC consultant used the IESC computer aided software engineering tool 
to model the data for review at the next meeting. 

By the end of the second cycle of meetings Bobby and the other 
NAVMASSO analysts had noticed some general differences in viewpoint in 
representatives of Atlantic and Pacific fleets. The Atlantic fleet 
representatives seemed to expect a greater amount of top-down supervision 
and less flexibility in the system at the operational level. They also 
expected reports to higher authority to contain more detail. Finally, the 
East coast representatives modeled a system where more help was extended 
down the chain in terms of outside organizations providing supplemental 
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parts tracking services and similar functions. The analysts also noticed 
that representatives of the submarine community saw the testing records 
and certification of nuclear related parts as a top concern while aviators 
seemed more concerned with tracking the return of equipments for repair. 

Successive meetings of the user groups encountered weeks of delays 
due to varying opinions expressed by senior storekeepers and supply officer 
representatives from various commands and from representatives of the 
same commands at successive meetings. More than once, these 
disagreements as to the nature of basic entities to be modeled negated the 
majority of the work accomplished at a preceding meeting. Disagreements 
among participants were intensified by the fact that the meetings tended 
to alternate between coasts with Atlantic fleet participants attending east 
coast meetings and Pacific fleet representatives attending west coast 
meetings. Since the Atlantic and Pacific fleets have their own sets of 
instructions and reporting requirements dealing with shipboard supply 
procedures, groups from these two fleets tended to have differing views on 
which reports were required and what procedures were critical and which 
superfluous. Even more frustrating to the analysts was the fact that even 
on the same coast the changing representatives from a command would 
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often vary in their views from meeting to meeting thus causing 
backtracking and reexamination of completed areas. 

Despite these formidable obstacles to progress, the analysts were able 
to develop cohesive groups of entities in three out of four functional areas 
by the fall of 1990. Financial was the functional area not completed, 
possibly due to an inability to resolve the differences between afloat and 
ashore accounting practices. With this exception, the analysts believed they 
were ready to evaluate the SMMS model as a whole with the end users. 
Unfortunately Operation Desert Storm work requirements had almost 
totally depleted the pool of users who would otherwise do the evaluation 
and the project went into a holding pattern. 

During the delay, the fact that the computer aided software 
engineering tool in use was centered mainly on data modeling and did not 
provide support for code generation was reevaluated by the project steering 
committee. In order to take advantage of potential cost savings in code 
generation and software maintenance costs, CASE tools with code 
generation capability were considered. Despite the fact that translation of 
the work done to date was not guaranteed by the company, the decision was 
approved by Admiral Moore’s committee to use a new CASE tool for the 
remainder of the project. IESC who had been in on the data modeling work 
was discharged but four copies of their software were purchased with the 



26 



idea that in-house staff could maintain the data model already developed 
and to aide in translation to the new model. As late as June 1991 only one 
copy of the software had actually been loaded and had proved of limited 
utility in the transition process. 

Three new integrated CASE tools produced by Oracle were chosen. 
Oracle’s tools define business applications instead of business functional 
areas as a starting point. The twenty five business functional areas were 
grouped into nine business applications. The first three of nine applications 
to be defined and the first to be worked were material id, organization, 
material procurement. Translation of work completed using the IESC 
CASE tool to the new Oracle CASE tool has proven difficult at best. 

In order to more clearly define fleet requirements Admiral Moore 
directed COMNAVSUPSYSCOM to survey the fleet user. Due to an 
imminent transfer by the Captain in charge of sending the survey, an 
extensive four-part and 200 page questionnaire was hastily sent out to all 
the users and subsequently reduced in scope to type commanders only. The 
loose organization and redundant nature of the questions in the survey as 
well as the length impair its usefulness. The initial impact was to delay 
any further user input meetings by two to six months pending return and 
evaluation of survey results. 
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B. OTHER CONSIDERATIONS 



The Oracle CASE tool generates code in a proprietary language SQL 
Forms rather than Ada. While exceptions to the use of Ada as a 
programming language in DOD could be obtained, there had been no 
commitment to use SQL Forms for other non-tactical shipboard 
applications. SQL Forms was also not listed as one of the higher level 
languages approved for use by the Department of Defense(DoD 3405.1, 
1987). Use of a non-standard language may impede future communications 
between and integration of shipboard systems. 

A separate group of analysts at NAVMASSO was working on a project 
to reverse engineer half a dozen automated shipboard and shore 
maintenance tracking programs. These programs have been developed by 
type commanders and program managers to track maintenance actions on 
different pieces or types of shipboard equipment. At least one system 
developed for NAVSEA, the maintenance resource management system 
(MRMS), has two versions one for SNAP I sites and one for non-SNAP I 
sitesfPRC, 1991). Integration of these programs with other shipboard 
software has not been a firm requirement. This lack of interoperability may 
be due to the lack of emphasis and non-availability of technology at the 
time when the programs were developed. The analysts are attempting to 
extract and preserve the best parts of each separate system in a 
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standardized system. Even though this system will need to communicate 
in some fashion with the supply software no commitment had yet been 
made to any data model or specific software. 

There also non-funded long term goals of eventually including other 
supply areas as well as shipboard administrative functions in a centralized 
ships data base(Winston, 1991). While these considerations have not yet 
received the credibility of being funded their importance may increase with 
the continued shift toward minimum manning and maximum efficiency of 
shipboard activities and equipment. 

In June 1991, no consideration had been given to a direct linking of the 
computerized data in the ship’s co-ordinated shipboard allowance list with 
the supply module. Such a link might help insure that the system reflected 
the latest in ships on board equipment and likewise was not ordering parts 
for equipment that had been removed in overhauls. 

The Oracle vendor estimated that the run time modules needed to run 
their proprietary software on local area networks (LANs) on ships would 
run about $150 per copy(Oracle, 1991). The SQL Forms language had no 
capability to communicate with CD ROM based technology for updating of 
price, stock number or other data. Due to the decreasing cost and highly 
portable nature of CD ROM technology, this lack of compatibility may limit 
future expansion. 
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Currently, none of the Navy’s ashore accounting systems have been 
certified by the GAO mainly due to the lack of depreciation 
capability(Eberling, 1991). The data requirements of such a new system 
were not known in 1991. This lack of guidance could be a major challenge 
to progress on the financial aspects of SMMS. 

SNAP I release 3 (realtime) which had a very rocky start, with 
problems encountered in its processing of data and giving immediate or 
realtime updates to data. However, release 3 is starting to gain more 
acceptance by the pertinent divisions of the user group commands(Paite, 
1991). Especially when compared to the work involved and risks inherent 
with building and installing a totally updated system. Most of the users 
have been involved in at least one update or system implementation and 
know that every time a major change is made to a system there are 
undetected software problems that must be fixed retroactively. In an 
operational environment such problems with supply software would 
interfere with the units ability to fix broken equipment and reduce the 
supply systems credibility. In a worst case, the fix may take long enough 
to put the whole ship at risk. 

At least one user command is advocating the total reappraisal of what 
functions need to remain afloat and what ones can be brought ashore 
through a transaction item reporting system(Smith, 1991). Under this 
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concept, most accounting functions would be moved ashore. In the shore 
environment, tasks could be civilianized and performed by civil service 
employees trained in accounting. Even if the jobs were still done by 
military personnel, they could be specifically trained and have 
knowledgeable coworkers and a telephone consistently available. 
Transactions would be reported via electronic means on satellite links. If 
such a change were to be implemented it would require basic changes in the 
design of the SMMS system. 

C. VIEW FROM THE STEERING COMMITTEE 

The shipboard arena is one of the few Navy data processing areas that 
remains under direct Navy control. Keeping those shipboard systems viable 
and maintainable in a rapidly changing technological and fiscal 
environment is the challenge. Any move that appears to be wasteful or 
smacks of adding unnecessary nice to have items is sure to bring 
Congressional criticism and possible funding cuts. The Navy is operating 
in an environment where not even the number of type commanders is 
guarantied to remain constant but decisions must be made on continuing 
implementation of the current two SNAP systems as well as the pace and 
upgrading within those systems. Potential end users vary from an aircraft 
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carrier with a LAN consisting of over 200 units to small ships with stand 
alone PCs. 

D. YOUR CHARTER 

To prepare for the class discussion, adopt the perspective of the head 
of the Navy’s ADP steering committee. Your charter is to implement a 
strategy to meet the long term non-tactical information processing 
requirements of Naval afloat and ashore operational units. 
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VI. TENTATIVE CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

The realities of the way management information projects are 
budgeted, funded and implemented in the Department of the Navy are 
not unique. The command structure, billet rotation policies and 
specialization of functional tasking do give these processes characteristics 
that are worthy of study. 

A careful review and discussion of the case study in chapter 5 
should prove a fruitful source of potential pitfalls that face a large 
organization trying to modernize its data processing capabilities. Some 
of the pertinent questions that may be raised are: 

• What is the proper level of authority to control production and 
integration of data processing programs? 

• Is data modeling a workable and worthwhile activity and if so at 
what level of the organization should it be accomplished? 

• With split responsibility for production, training and maintenance of 
software can the true return on investment for updating and 
integrating software be calculated? 

• Are CASE tools adequately developed to be cost effective in the 
Navy software development process? 

• If CASE tools are to be used should contracts be written to hold 
vendors accountable for successful transition from another vendors 
product? And if written would any vendor bid on them? 
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• Can a poorly prepared survey do more damage than good? 

• Should a CASE tool be utilized that generates code in a proprietary 
language and requires run-time modules to execute? 

B. RECOMMENDATIONS 

These recommendations are based on the fact that the funding 
environment within DOD is constrained. Any project must be able to 
prove it is cost effective with a relatively short payback period. 

• If data modeling is to be done, it should be done at the ship wide 
level to allow integration of ship wide requirements. This will allow 
immediate savings in reduction of support for parallel systems. 

• New systems developed should utilize object oriented or other 
designs that allow enough flexibility to readily accept technological 
advances. 
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APPENDIX A 



This document is the cover letter and edited four sections of the 
survey sent out by COMNAVSUPSYSCOM to SNAP users. 
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AUTOVON 



IN REPLY REFER TO: 



0332 

4400 

24 MAY 1991 



From: Commander, Naval 

To: Distribution 

Subs: SUADPS RELEASE 3 



Supply Systems Command 
FUNCTIONAL ASSESSMENT 



Ref: (a) Functional Policy Council of April 1991 



Enel : 



(1) Afloat Business Systems Applications 
Comparison 

(2) Type Commander SUADPS Functional Evaluation 

(3) Type Commander SUADPS Functional Needs Assessment 

(4) Type commander SUADPS Reports Critique 



I. Pursuant to agreements made during the April 1991 Functional Policy 
Council, a comprehensive evaluation of SUADPS and SNAP II Supply and 
Financial Management system strengths and weakness is underway. The 
observations and recommendations of this study will influence the manner 
in which NAVSUP will pursue the development of the SNAP Material 
Management System (SMMS) . To assist in this evaluation, a comprehensive 
review of applications now addressed by SUADPS and a needs assessment of 
those applications not now included in SUADPS are required. 



2. To establish a baseline by which to measure the effectiveness of 
our current supply management systems, NAVSUP recently developed an 
afloat business systems applications matrix. This matrix totaled 219 
business applications considered necessary for modern afloat supply 
operations. NAVMASSO compared current versions of SUADPS, SFM, OMMS, 
NALCOMIS and ILM against this matrix. NAVMASSO' s findings, enclosure 
(I), are forwarded for information. NAVSEA PMS-331 has tasked the MRMS 
development contractor to likewise compare MRMS functionality against 
the matrix. The results of that comparison will be forwarded for 
information under separate cover. Overall, SUADPS was found to include 
automated routines for only 109 of the 219 business applications. 



3. To assess SUADPS effectiveness, a questionnaire, enclosure (2), is 
forwarded for each business application (109) now included in the 
current SUADPS release. Your comments on each application will 
determine whether a function is satisfactory as designed, unsatisfactory 
and in need of redesign, or a candidate for pierside support or other 
off-ship methods. 
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Subj : SNAP II SUPPLY AND FINANCIAL MANAGEMENT SYSTEM FUNCTIONAL 
ASSESSMENT 



4. For each application not now automated in SFM 5.10 (122), a 
questionnaire, enclosure (3), is also included. Your comments will 
influence whether this application will be automated in SMMS. 

5. Finally, your assistance is requested to evaluate the appropriateness of 
the reports now included in SUADPS. Your comments on enclosure (4) will 
influence whether these reports will be continued under SMMS, should be 
repositioned to a PC MIS environment, or dropped from use. 

6. Completing enclosures (2), (3) and (4) will require a thorough insight 

into he strengths and weaknesses of SNAP II SFM and a comprehensive 
understanding of how afloat supply officers and staffs now manage their 
affairs with the help of, and some times in spite of, our afloat business 
information management systems. Fleet support of this functional assessment 
is necessary to ensure that SMMS addresses our mutual needs and desires and 
concentrates on delivering the greatest benefit for our investment. 

7. It is requested that enclosures (2), (3) and (4) be completed and 

returned to NAVSUP 0332 by 15 July 1991. 



S. W. Baldwin 
Acting 

Assistant Commander 
Inventory & Systems Integrity 



Distribution: 
COMSUBLANT (NS) 
COMSUBPAC (N5 ) 
COMNAVSURFLANT (N7) 
COMNAVSURFPAC (N7) 

Copy to: (w/o ends) 

CINCLANTFLT (N4 ) 
CINCPACFLT (N4) 
NAVMASSO (01) 

NAVSEA (04 -TD) 

NSCS Athens (48) 
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Page No. 1 Enclosure (1) 

05/24/91 

APPLICATIONS FOUND IN VARIOUS AFLOAT BUSINESS SYSTEMS 



APPLICATION 

** BUSINESS FUNCTION: ALLOWANCE /TECH DATA 


SUADPS 


SFM 


OMMS 


NALCOMIS ILM 


* SUB FUNCTION: CONFIGURATION MGMT 


BASELINE 


N 


N 


Y 


Y 


Y 


CONFIGURATION CHANGES 


N 


N 


Y 


Y 


Y 


* SUB FUNCTION: TECHNICAL DATA 


TECH MANUALS 


N 


N 


Y 


Y 


N 


COMPONENT CHARACTERISTICS 


N 


N 


Y 


N 


Y 


* SUB FUNCTION: ALLOWANCE 


A PL QA 


P 


N 


Y 


N 


Y 


COMPUTATION REVIEW 


Y 


N 


N 


Y 


Y 


FCFBR 


N 


N 


N 


N 


N 


RANGE/DEPTH ANALYSIS 


Y 


Y 


N 


Y 


Y 


LOAD LIST EFFECTIVENESS 


Y 


N 


N 


N 


N 


* SUB FUNCTION: ILO/DECK LOAD SUPPORT 


CHANGE IN-FORCE STRUCTURE 


N 


N 


N 


N 


N 


REPAIR PARTS ANALYSIS 


N 


N 


N 


N 


Y 


CONFIGURATION ANALYSIS 


N 


N 


N 


N 


Y 


TECHNICAL DOCUMENTATION 
ANALYSIS 


N 


N 


N 


N 


N 


LOAD LIST ANALYSIS 


N 


N 


N 


N 


Y 


LOGISTICS READINESS 


N 


N 


N 


N 


Y 


2M SUPPORT 


N 


Y 


N 


N 


N 
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Page No. 2 
05/24/91 

APPLICATIONS FOUND IN VARIOUS AFLOAT BUSINESS SYSTEMS 



APPLICATION 



CATEGORY SUADPS SFM OMMS NALCOMIS 



** BUSINESS FUNCTION: BUSINESS OPERATIONS 



* SUB FUNCTION: MATERIAL REQUESTS 
ACCEPT CUSTOMER MATERIAL 
REQUESTS 

EDIT MATERIAL REQUESTS 
PROCESS REQUIREMENTS FOR 
ISSUE /REFERRAL 
MONITOR REQUISITION STATUS 
MODIFY, CANCEL, FOLLOW-UP 
REQUISITIONS 

NON-STANDARD MATERIAL REQUESTS 
RESCREEN 

CANNIBALIZATIONS/ PAYBACKS 
UNREP PLANNING 
SERVICE REQUESTS 



Y 

Y 

Y 

Y 

Y 

P 

P 

N 

Y 

Y 



Y 

Y 

Y 

Y 

Y 

Y 
N 
N 
N 

Y 



N 

N 

N 

N 

N 

N 

N 

N 

N 

N 



Y 

Y 

Y 

Y 

Y 

N 

Y 

Y 
N 
N 



* SUB FUNCTION: DLR MANAGEMENT 
CARCASS TRACKING 
2M CHECKS /CERTIFICATION 



Y Y N Y 

N N N Y 



* SUB FUNCTION: EXPENDITURES 

MATERIAL DISPOSITION DEFICIENT 

MATERIAL 

MATERIAL DISPOSITION HAZ WASTE 

MATERIAL DISPOSITION EXCESS 

SCRAP 

SURVEY PROCESSING 
ROD PROCESSING 
QDR PROCESSING 
TDR PROCESSING 



Y 

N 

Y 
N 

Y 
N 
N 
N 



Y 

N 

Y 
N 

Y 
N 
N 
N 



N 

N 

N 

N 

N 

N 

N 

N 



Y 

P 

Y 
N 
N 
N 

Y 

Y 



* SUB FUNCTION: EXPEDITING 

ID HOT REQUISITIONS 

ON-LINE MANAGEMENT 

HOT REPORTS 

HOT REPORTS 

HOT REPORTS 

HOT REPORTS 

HOT REPORTS 

HOT REPORTS 



N 

Y 

CASREP N 

NMCS/PMCS N 

AWP N 

WORK STOPPAGE N 
HOT JCN 

SPECIAL N 

PROJECTS 



Y N Y 

Y Y Y 

Y N N 

Y N Y 

N Y Y 

N N Y 

N Y N 

Y N Y 



SUB FUNCTION: MOV 
EXTERNAL ICP MOV PROCESSING 
INTERNAL MOV PROCESSING 



Y Y N N 

Y Y N N 
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ILM 



Y 

Y 

Y 

Y 

Y 

N 

N 

N 

N 

N 



N 

N 



Y 

N 

Y 
N 
N 
N 
N 
N 



Y 

Y 
N 
N 
N 
N 
YN 
N 



N 

N 



Page No. 3 
05/24/91 

APPLICATIONS FOUND IN VARIOUS AFLOAT BUSINESS SYSTEMS 
APPLICATION CATEGORY SUADPS SFM OMMS NALCOMIS ILM 



** BUSINESS FUNCTION: CONTROL 



* SUB FUNCTION: CONSTANTS 
SYSTEM CONSTANTS 
VALIDATION TABLES 
LOCAL CONSTANTS 
COUNTERS 



Y Y N N 

Y Y N Y 

Y Y N N 

Y Y N N 



* SUB FUNCTION: SECURITY 

USER ACCESS 

MAN HOUR ACCOUNTING 

MAN HOUR DATA PER TRANSACTION 



Y Y N Y 

N N N N 

N N N N 



* SUB FUNCTION: ADP OPERATIONS 

BACK/UP 

RECOVERY 

ADP SCHEDULING 

SYSTEM CONFIGURATION MODULE 

MANAGEMENT 



Y Y N Y 

Y Y N Y 

Y Y N N 

Y Y N N 



SUB FUNCTION: TRANSACTION RECORDING 

PURGE TO HISTORY 
CTL PROCESSING 



Y Y N P 

Y P N N 
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Page No. 4 
05/24/91 

APPLICATIONS FOUND IN VARIOUS AFLOAT BUSINESS SYSTEMS 
APPLICATION CATEGORY SUADPS SFM OMMS NALCOMIS ILM 



** BUSINESS FUNCTION: EXTERNAL INTER ACES 



* SUB FUNCTION: 
NALCOMIS 


ON-LINE INTERFACES 


Y 


N N 


Y 


OMMS 




Y 


Y Y 


N 


MRMS 




Y 


N N 


N 


IMMS 




Y 


N N 


N 


UADPS 




N 


N N 


Y 


UICP 




N 


N N 


N 


SCLSIS 




N 


N Y 


N 


APADE 




N 


N N 


N 


DEPRA 




N 


N N 


N 


DDN 




N 


N N 


Y 


PCMT 




N 


N N 


N 


ASCC 




N 


N N 


Y 


ADM 




N 


Y N 


N 


MSDS 




N 


Y N 


N 


SAMS 




N 


Y N 


N 


SPLICE 




N 


N N 


N 


* SUB FUNCTION: 
CHANGE NOTICE 


BATCH INPUTS FROM 


Y 


N Y 


Y 


AS I 




P 


Y Y 


N 


COSAL 




Y 


N Y 


N 


AVCAL 




Y 


N N 


Y 


TARSLL 




Y 


N N 


N 


FILL 




Y 


N N 


N 


FAADC TAPES 


SFOEDL 


N 


N N 


N 


FAADC TAPES 


C&H 


Y 


N N 


N 


FAADC TAPES 


OTHER 


N 


N N 


N 


RRTMIS 




N 


N N 


N 


E38 




Y 


N N 


Y 


ICP DEMAND 




N 


N N 


N 


CYCLIC ASSET 




N 


N N 


N 


* SUB FUNCTION: 
RRIMIS 


BATCH INPUTS TO 


Y 


N N 


N 


CYCLIS ASSET 




Y 


N N 


N 


PMO 




Y 


N N 


N 


PARENT TENDER 




Y 


N N 


N 


* SUB FUNCTION: 
SNAP II 


BATCH INPUTS TO/FROM 


Y 


P N 


N 


SUB FUNCTION: 
SUADPS 


ON-LINE INTERFACES 


Y 


N N 


Y 
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Page No. 5 
05/24/91 

APPLICATIONS FOUND IN V IOUS AFLOAT BUSINESS SYSTEMS 
APPLICATION CATEGORY SUADPS SFM OMMS NALCOMIS ILM 



** BUSINESS FUNCTION: FINANCIAL 



* SUB FUNCTION: OM,N 
SHIP'S GRANT ACCOMMODATION 
DEPARTMENTAL BUDGET MANAGEMENT 

SHORE LIST PROCESSING SFOEDL/AUOL 

TRANSMITTALS ASHORE BOR/TL 

PROJECT ACCOUNTING 

BUDGET FORECASTING 

BUDGET EXECUTION GRAPHICS 

REPORT OF CREDITS 

ROV AVAILABILITY COST REPORT 

FLIGHT HOUR ACCOUNTING 

* SUB FUNCTION: NAVY STOCK FUND 
TRANSMITTAL OF NSF DETAIL 
ASHORE 

FAADC RECONCILIATION DATA 

PROCESSING 

SAC 224 PROCESSING 



Y 


Y 


N 


N 


N 


Y 


Y 


N 


N 


N 


P 


Y 


N 


N 


N 


Y 


Y 


N 


N 


N 


N 


N 


N 


N 


N 


N 


P 


N 


N 


N 


N 


N 


N 


N 


N 


Y 


N 


N 


N 


N 


Y 


N 


N 


N 


N 


P 


N 


N 


N 


N 


Y 


N 


N 


N 


N 



N 



N 



N 



N 



N N 



N 



N 



* SUB FUNCTION: OTHER ACCOUNTING 

OPN ACCOUNTING 

SCN ACCOUNTING 

TOB ACCOUNTING 

SHIP'S STORE ACCOUNTING 



N Y N N 

N N N N 

N N N N 

N N N N 
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Page No. 6 
05/24/91 

APPLICATIONS FOUND IN VARIOUS AFLOAT BUSINESS SYSTEMS 



APPLICATION CATEGORY SUADPS SFM OMMS NALCOMIS ILM 



** BUSINESS FUNCTION: I -LEVEL MAINT SUPPORT 



* SUB FUNCTION: COMPONENT CONTROL 

INDUCTIONS 

REPAIR AND RETURN 

CANNIBALIZATIONS/ PAYBACKS 

CONDITION CODE TRANSFERS 

El MANAGEMENT 

RFI RETURN 

NRFI RETURN 

FLR MANAGEMENT 

2M MANAGEMENT 

AWP MANAGEMENT 

MAINTENANCE ACTION REPORTING 



N N N Y 

P N N Y 

N N N Y 

N N N N 

N N N Y 

Y N N Y 

Y Y N Y 

P Y N Y 

N Y N N 

N N N Y 

Y N N Y 
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Page No. 7 
05/24/91 

APPLICATIONS FOUND IN VARIOUS AFLOAT BUSINESS SYSTEMS 
APPLICATION CATEGORY SUADPS SFM OMMS NALCOMIS ILM 



** BUSINESS FUNCTION: INVENTORY 



* SUB FUNCTION: MAINTAIN DATA 



UPDATE MANAGEMENT DATA 




Y 


Y 


Y 


Y 


MAINTAIN INVENTORY BALANCE BY 




N 


Y 


N 


N 


LOCATION 

MAINTAIN INVENTORY BY OTHER 


BY LOT 


N 


N 


N 


N 


VARIABLES 

MAINTAIN INVENTORY BY OTHER 


CONTRACT 


N 


N 


N 


Y 


VARIABLES 

MAINTAIN INVENTORY BY OTHER 


NUMBER 
SHELF LIFE 


N 


Y 


N 


N 


VARIABLES EXPIRATION 

* SUB FUNCTION: MANAGE STOCK LISTS 
DEMAND HISTORY COLLECTION 


Y 


Y 


N 


P 


LEVEL SETTING 




Y 


Y 


N 


N 


REPLENISH 




Y 


Y 


N 


Y 


EXCESS MANAGEMENT 




Y 


Y 


N 


N 


* SUB FUNCTION: VALIDITY FUNCTIONS 
PHYSICAL INVENTORY 


Y 


Y 


N 


Y 


RECONCILIATION 




P 


Y 


N 


Y 


CAUSATIVE RESEARCH 




P 


N 


N 


Y 


ADJUSTMENTS 




Y 


Y 


N 


N 


* SUB FUNCTION: SPECIAL INVENTORIES 
SEAMART 


P 


N 


N 


N 


FUEL 




P 


N 


N 


N 


SHELF LIFE MATERIAL 




Y 


Y 


N 


N 


SUSPENDED MATERIAL 




N 


Y 


N 


Y 


GAS AND CYLINDERS 




P 


Y 


N 


N 


HAZMAT 




P 


Y 


N 


N 


Q COSAL MATERIAL 




y 


Y 


N 


N 


DLRS 




Y 


Y 


N 


Y 


LEVEL I /SUBSAFE 




p 


N 


N 


N 


NUKE WATER CHEMICALS 




p 


N 


N 


N 


AMMUNITION 




N 


N 


N 


N 


LOCAL ROTABLE POOL ASSETS 




N 


N 


N 


Y 


EQUIPAGE 


MHE 


N 


N 


N 


N 


EQUIPAGE CONTROLLED 


EQUIPAGE 


N 


Y 


N 


N 


EQUIPAGE OTHER 


CRITICAL 


N 


Y 


N 


N 


MAMS 




N 


Y 


N 


N 


OSI/RSS 




N 


Y 


N 


N 


GPETE/SPETE CALIBRATION 


LAB 


N 


Y 


N 


P 


PROVISIONS 




y 


N 


N 


N 


SHIPS STORE IQ COG MATERIAL 




y 


Y 


N 


N 


PRE-EXPENDED BIN MATERIAL 




Y 


N 


N 


Y 


OUTBOUND PACKUP 




Y 


N 


N 


Y 


INBOUND PACKUP 




Y 


N 


N 


Y 



N 

N 

N 

N 

N 

N 
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Page No. 8 
05 / 24/91 

APPLICATIONS FOUND IN VARIOUS AFLOAT BUSINESS SYSTEMS 



APPLICATION CATEGORY SUADPS SFM OMMS NALCOMIS ILM 



STRATEGIC WEAPONS MATERIAL 
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Page No. 9 
05/24/91 

APPLICATIONS FOUND IN VARIOUS AFLOAT BUSINESS SYSTEMS 
APPLICATION CATEGORY SUADPS SFM OMMS NALCOMIS ILM 



** BUSINESS FUNCTION: PERFORMANCE MONITORING 



* SUB FUNCTION: INVENTORY 

DEMAND EFFECTIVENESS 
ALLOWANCE EFFECTIVENESS 
UMMIPS PERFORMANCE 
RANGE/DEPTH ACCURACY 
INVENTORY ACCURACY 
CAUSATIVE RESEARCH RESULTS 



Y 

Y 

Y 

Y 

Y 
N 



Y 

Y 
N 

Y 

Y 
N 



N 

N 

N 

N 

N 

N 



P 

Y 
P 

Y 
N 
N 



N 

N 

N 

N 

N 

N 



* SUB FUNCTION: FINANCIAL 
NSF STATUS 
BUDGET EXECUTION 
ADJUSTMENT MEASUREMENT 



P 

N 

N 



Y 


N 


N 


N 


Y 


N 


N 


N 


Y 


N 


N 


N 



* SUB FUNCTION: WORKLOAD 
ACTION PROCESS TIME 
AVG CUSTOMER WAIT TIME 
EXCEPTION MEASUREMENT 
ENDURANCE 
PERSONAL WORKLOAD 
PERSONAL PRODUCTIVITY 
QA PROGRAM 



N 

N 

N 

N 

N 

N 

N 



N 

N 

N 

N 

N 

N 

N 



N 

N 

N 

N 

N 

N 

N 



Y 

Y 
N 
N 
N 
N 
N 



N 

N 

N 

N 

N 

N 

N 



SUB FUNCTION: PHYSICAL DISTRIBUTION 
RRTMIS N 

PROCESS CONTROL N 



N N N N 

N N N N 
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Page No. 10 
05/24/91 

APPLICATIONS FOUND IN VARIOUS AFLOAT BUSINESS SYSTEMS 
APPLICATION CATEGORY SUADPS SFM OMMS NALCOMIS ILM 



** BUSINESS FUNCTION: PHYSICAL DISTRIBUTION 



* SUB FUNCTION: INBOUND MATERIAL 

RECEIPT IN PROCESS 

CHARACTERISTICS 

RECEIPT IN PROCESS 

CHARACTERISTICS 

RECEIPT IN PROCESS 

CHARACTERISTICS 

RECEIPT IN PROCESS 

CHARACTERISTICS 

RECEIPT IN PROCESS 

CHARACTERISTICS 

RECEIPT IN PROCESS 

CHARACTERISTICS 

RECEIPT IN PROCESS 

CHARACTERISTICS 

RECEIPT IN PROCESS 

CHARACTERISTICS 

STAGING FOR TURNOVER 

STAGING FOR STOW 

STOW 

STOW 

PROOF OF DELIVERY 



LOT SIZE 

CONT CT 
NUMBER 
PACK ATE 

SHELF LIFE 
CUBE 

DESTINATION 

CLEAN 



Y Y N Y 

N N N N 

N N N Y 

N N N N 

N N N N 

N N N N 

N N N N 

N Y N N 

N Y N N 

N Y N N 

N Y N N 

N Y N N 

N Y N Y 



Y 

Y 

Y 

Y 

Y 

Y 

Y 
N 



* SUB FUNCTION: STOREROOM MGMT 
STOWAGE PLAN 

LOCATION CHARACTERISTICS 
LOCATION CHARACTERISTICS 
LOCATION CHARACTERISTICS 
LOCATION CHARACTERISTICS 
LOCATION CHARACTERISTICS 
LOCATION CHARACTERISTICS 

RESTOWAGE 

LABELLING 

LABELLING 





N 


N 


N 


SIZE 


N 


Y 


N 


SECURITY 


N 


N 


N 


WEIGH LIMITS 


N 


N 


N 


CUBE LIMITS 


N 


N 


N 


TYPE MATERIAL 


N 


Y 


N 


MATL 


N 


Y 


N 


COMPATIBILITY 


N 


Y 


N 


MATERIAL INFO 


Y 


Y 


N 


STOW CATION 


Y 


Y 


N 



N 

N 

N 

N 

N 

N 

N 

N 

N 

N 
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page No. 11 
05/24/91 

APPLICATIONS FOUND IN VARIOUS AFLOAT BUSINESS SYSTEMS 



APPLICATION SUADPS SFM OMMS NALCOMIS ILM 



* SUB FUNCTION: OUTBOUND MATERIAL 



PICK 

STAGE 

PREPARE DOCUMENTATION 
PACK/ CRATE 
RETROGRADE HANDLING 
PROOF OF SHIPMENT 
TRANSHIPMENTS 

ENGINEERING INVESTIGATIONS 

TURN-INS 

TURN-INS 

TURN-INS 

TURN-INS 



Y N N 
P N N 

Y N N 
N N N 

Y N N 
N Y N 
N Y N 
N N N 

MTIS Y Y N 

SUPPLY CENTER Y Y N 

DRMO Y Y N 

DLRS Y Y N 



Y 
N 

Y 
N 

Y 
N 
N 

Y 

Y 
N 
N 

Y 



* SUB FUNCTION: PLANNING 
WORKLOAD SCHEDULING 
PHYSICAL CONSTRAINTS 
T-SHED BACKLOAD MANAGEMENT 
UNREP PLANNING 
UNREP PLANNING 
UNREP PLANNING 
UNREP PLANNING 



PROVISIONS 

BULK 

BIN 

TURNOVER 



P N Y Y 

N N N N 

N N N N 

Y N N N 

Y N N N 

Y N N N 

Y N N N 
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Enclosure (2) 

TYPE COMMANDER SUADPS FUNCTIONAL EVALUATION 



BUSINESS FUNCTION: 
SUB FUNCTION: 
APPLICATION: 
CATEGORY : 

EVALUATOR: 



90 sheets total 
one for each 
Y under SUADPS 
in enclosure (1) 



COMMAND/CODE/TELEPHONE: 



NO 

l.a. Is this application necessary? 123 

1. b. If 2, 3, 4, why? (rank in order of importance: A, B, C, D) 

Needed for supply officer or staff decision making: 

Needed for customer decision making or information: 

Needed for internal process control: 

Needed for external reporting: 

Needed for internal higher management reporting: 

2. Is this application easy to use? 123 

3. Do operators have to "trick" the system to get this 

application to work? If 2, 3, or 4 explain: 123 



3. Is OJT sufficient training for operators to become 

proficient in the use of this application? 123 

4. Is "Shiprider" assistance necessary to successfully 

use this application? 123 

5. Are clear instructions available on how to use this 

application? 123 

6. Do problems frequently occur using this application? 

If 2, 3, or 4 , explain: 123 



7. Does this application provide sufficient 123 

information? If 1, 2, or 3, explain what is missing. 



8. Should this business application be done ashore? 123 
If 3 or 4, explain how: 



9. What improvements would you suggest for any aspect 123 
of this application? 



YES 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 
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TYPE COMMANDER SUADPS 

BUSINESS FUNCTION: 

SUB FUNCTION: 

APPLICATION: 

CATEGORY : 

EVALUATOR: 

COMMAND/CODE/TELEPHONE: 



Enclosure (3) 

FUNCTIONAL NEEDS ASSESSMENT 

108 sheets total 
one for each 
N under SUADPS 
in enclosure (1) 



THIS APPLICATION IS NOT IN SUADPS BUT MAY BE PLANNED FOR A 
LATER RELEASE PLEASE ANSWER THE FOLLOWING QUESTIONS: 

NO 

l.a. Should this application be automated in SUADPS? 123 

1. b. If 2, 3, 4, why? (rank in order of importance: A, B, C, D) 

Needed for supply officer or staff decision making: 

Needed for customer decision making or information: 

Needed for internal process control: 

Needed for external reporting: 

Needed for internal higher management reporting: 

2. What information should this application provide? 



3. In what form should the information be provided? 



4. Is this application now performed manually? 123 

4. a. If 3 or 4, what skill level is needed to accomplish 
the task? 

Officer CPO LPO PO SN 

4.b. If 3 or 4 , how often is this application accomplished? 
Deployed: 



Annua 1 ly 


Monthly 


Weekly 


Daily 


In home port : 
Annually 


Monthly 


Weekly 


Daily 


During Availabilities: 






Annua 1 ly 


Monthly 


Weekly 


Daily 



5. Has this application been automated with the use of locally 
developed software? 



YES 

4 



50 



SUAEPS FIAN7GEFJENT FETCRI5 ANALYSIS 



TYCCM: EVALUATOR: 

nr kncticr repcrt full name 




REQUISTnCN FILE HUNT 
ISSUE HNDDC FILE (REKKT 2) 

008 S^WSAL 

008 SAMFyEAL FART 1 TOTAL EE3ML 

008 SAMFy'SAL FART 2 DOLLAR VALLE BY AT CCCE 

008 SAMFPy'SAL PART 3 LEA EE2ML REKKT 

008 SAMFy'SAL PART 4 APA FCNT OF SAL EEIAIL 

008 SAM-Fy'SAL PART 5 INVENTORY FSVFGEMENT 

009 CD5AL AFL ANALYSIS (USID C & M) 

009 CDSAL FERCENIAffi (USID A, B, T) 

009 CCSAL PERCENTAGE (USID C AND M) 

009 AVCAL PIC AF&LYSIS 

009 AVAL PERCENTAGE 

Oil FASTER STOCK SIAILS 

015 OPIAR HISTORY FILE FROCESSHG REKKT 

036 ISSUES CF (XNIRQLIED EKJG SUBSTANCES 

044 FFD EEFPND RETORT 

051 EXCESSIVE IDCAnOE LISTDC 

051 ICCALICN AUDIT USITFG 

051 FAIL CN H?ND - ND LOCAIICN 

051 FEP MATERIAL - EFKNEQU5 IOCATTCN LISTDG 

051 QUANTITY VAHDAITCN (FART CNE) 

051 QLA.MTIY VAIIDAIICN (FART TWO) 

054 DLR FKTNT REKKT 



RE 


REQUIRED EXIEENAL 


FREQUENCY CDCES: D 


DAILY 


W 


WEEKLY 


RE 


REQUIRED INTERNAL 


M 


flnihly 


Q 


QUARTERLY 


IM 


INihRAL FW4AG£MENT 


Y 


YEARLY 


A 


AS REQUIRED 



1 
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SUMPS FONA2MENT FETCHES ANALYSIS 



TYCCM: EVALUATOR: 

UL FLNCTKU REFCRT FULL NAME 

056 FKEERIAL 0BLICAT1CN VALTOAITCN CPIICN 1 

056 MATERIAL CHLIGATICN VALTOKITON CPIICN 2 

056 ' MAURIAL CBLEGAIICN VAUEKITON CPIICN 3 

056 FKEERLAL CBLiaTICN VAITODAITON CPIICN 4 

056 MATERIAL CBLIGAIICN VAUDAIICN CPIICN 5 

056 MAHRLAL CBLIGAIICN VALIIAITCN CPIICN 6 

056 FKURIAL CBLIGAIICN VALTCAITCN CPIICN 7 

057 EEFPND RETORTING 

058 EEFOT LEVEL REPAIRABLE CARCASS TRACKING 

060 CaSDLmAHI) BACKUP lisiug 

061 RBJi RESKNSE TIME MIS 

062 IMCIPS FERFCFJ'ANCE REFCRT 

064 QUARTERLY ASSET RETORT 

064 TYCCM RETORT 

065 EXTENDED MNEY VAIUE CF DID FEQUISTIiaE 

071 DIO DUES WTIH FKTERIAL CN HAND 

072 AUKMATIC FGHLOHJP READY FCR RELEASE 

073 DEMAND HISTORY FRXESSHC REFCRT 

074 DEMAND WE CNE-LENE 

080 MASTER STOCK STA3U3 AND LOCATOR LISIIN3 

083 OFFLOAD BY EXTENDED FENEY VALUE 

084 inventor: frdgkess retort 

084 PCYENIIAL GAINS AND LCSSES BY INVENTORY 

09 CM H4F RBTORD DFIFTF 

09QR REQUISTIICN PRINTOUT 



TEE - 

cdce 



OFUSE 

CDCE 



W 




USE CDCES: RE 

RI 
IM 



REQUIRED EXURNAL FREQUENCY CUES: D DAILY 
REQUIRED INTERNAL M FENIHLY 

INTER AL FANAGEMENT Y YEARLY 

2 



W WEEKLY 
Q QUAREE RIY 
A AS REQUIRED 
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TYOCM: 

Cd FLNCTEF 



SUACFS MANA2MENT REKKTS ANALYSIS 

EVAUJA1CR: 

REPORT FULL NAME CEE 



T 



oxe 



091 SURFACE MA3NIEN?NCE DATA SYSTEM REKKTDC 

093 GROUP CMCFUMIOI REQUEST 

094 RHJTFT IN FRDGSSS 

096 AVIKEKK FPJNIENANCE DATA SYSTEM FEKKITN3 

100 CEM^NDING OFFICER'S BUDST (REKKT 21) 

100 EEEARIMENr BUDGET (REKKT 21) 

100 DTV35ICN BUDCET (REKKT 21) 

100 INVENTORY ADJUSIMENT FEKKT 

100 REKKT 03 FINANCIAL INVENTORY REKKT 

100 REKKT 04 MKIHLY R3CELPT REKKT 

100 REKKT 04 MKIHLY REEEEPIS FEKKT 

100 REKKT 05 MKIHLY TRANSFER TO DISPOSAL 

100 REKKT 05 090 TRANSFER 

100 REKKT 06 NC 2074 CHARGES 

100 REKKT 07/08 NA\*XMPT 176 NBA RCV A&3 SUM 

100 REKKT 09 NAMGCMPT FCFM 2051 

100 REKKT 10 SUPFLY EFFECTIVENESS FEFCKT 

100 REKKT 20 UNFTIIH3 CHER SLM4AKY 

100 REKKT 22 OELIGAIED/EXFeLED DIFFERENCES 

100 REKKT 23 FRICK FISCAL YEAR TRANSACTION 

100 REKKT 24 FEG FEFCKT CF CREDITS 

100 REKKT 26 FLIGHT CPS BUDKT OPIAR 

100 REKKT 28 AFM BUDGET CPIAR 

100 REKKT 34 INVENTORY ADJUSTMENT FEFCKT 

100 REKKT 41 SUPPKT UNTI5 BK 



OFUSE 

axE 



WEFT 




LEE CDCE5: FE 

RI 
IM 



REQUIRED EXTEKKL FREQUENCY CDCES: D DAILY 
REQUIRED INTERNAL M MKIHLY 

INHKNAL FAF&GEMEOT Y YEARLY 



3 



W WEEKLY 
Q QUAFCTEKLY 
A AS REQUIRED 
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SUAEFS MANAGEMENT REPCJTS ANALYSIS 



TVCCM: EVAIDATOR: 

EC FLNCTKE EEPCRT FULL NAME 

100 REPCFT 42 REIMBLRSAELE BUDGET CPU®. 

100 REPCFT 46 RCV AVAILABILITY OUST REPCFT 

100 REPCFT 47 SEETHES AND EQUIPAGE BCR 

100 REPCFT 49 USD B AND T 

100 SAC 207 REP3TS 

100 STOCK ASSET DOLLAR VAIIJE EXIS'SICN 

100 SLM’AKY FTEID CFEEiyE^STNDING DIFF LIST 

100 SLPTOTED HOTS BCR FEG 

101 FIXED ALLOWANCE MRNB3MENT EEVEEW REFCFT 

CRi CLM RECEIPT FILE FROGESSL G REPCFT 

CTL FINANCIAL TRA. V SATTCN LEXER 

CTL MATERIAL TRANSACTICN FEEOT 

CEL QCDSAL TRAASVTICN REPOT 

CEL REQUISTITCN TRANSAdlCN LEDGER 

FBI PQLARIS/TCSFTDCK FMS REPOT 

M7T MASUR VALIDAIICN TABLE HTNTOUT 

CSO CLMJLA3TVE CS0 FTLE PROCESSING REFOT 

CSIAR CFEER AND SLIP TINE ALPLYSIS 

FED BATCH RECEIPT 

RFH CLM FISCAL YR TO DA3E RECEUT LISTING 

SSP SLSFENEED TRAFSACITCN 

SUNXR SLM-PPIZAIICN OF INAUIH3TZED CN CFDER 

SUNXR CANCELLED STOCK ITEMS CVEP. 30 CAYS 

SUNXR CANDDAIES FCR FARIIAI/FULL CAN CET I A TTCN 



LEFT 

axE 



OTjBcr 

OFlSE 

cdce 



wnr 




FE 


REQUIRED EXTERNAL 


FREQUENCY CDCES: D 


DAHL’ 


W 


WEEKLY 


FT 


REQUHTD B7IERJAL 


M 


M2THLY 


Q 


QIWTERLY 


IM 


INTERNAL MANA2MEIT 


Y 


YEARLY 


A 


AS REQUIRED 



4 
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SHADES MANAGEMENT FEFCRTS ANALYSIS 



TYCCM: 

nr FHNcsrar 



EVALUATOR: 
"HEKRT FULL.NAME 



U*EX CARCASS CEUAIL REKKT 

IN-EX ADJUSTED CANDDIA11CNS 

Ui<EX UWAICHED CAPnCNS C, H AND J 

UNEX UiEKHED EXPENDITURE 

INEX UWAICHED EXPENDITURE ADJ SUM-ARY 

UNEX 11MEX PROCESSING SUMMARY 

UmHY AMI TRANSFER REKKT 

UTILITY ISSUE PENDENS FILE (REPORT 3) 

X43 SURREY REKKT 

X43 QCESAL SURVEY REKKT 

X49 PAINIAINING CURRENCY CF AFPFDFRIATDC 

X49 DATA 

XB4 POTENTIAL GAIN/IOSS FFCM SCHED JNVENICRY 

XB4 BAICH ERKR REKKT 

zoc requisitions requiring local procurement 

ZOC TRANSACTIONS PLEASED TO PARENT TENTER 

ZOC TRANSACTIONS RELEASED FTCM SUPPLY 



CEE 

axE 


nmecr 

CFUSE 






axE 


(LOW) 



USE CDCES: RE 

RI 
IM 



REQUITED EXIEJNAL FREQUENCY CDCES: D DAILY 
REQUIRED INIEPNAL M M2NIHLY 

INTER-AL MANAGEMENT Y YEARLY 



5 



W WEEKLY 
Q QLARTEKY 
A AS REQUIRED 
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APPENDIX B 

This document is a collection of the cover letters sent in 
response to survey in appendix A. 
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DEPARTMENT OF THE NAVY 

COMMANDER SUBMARINE FORCE 
U S ATLANTIC FLEET 
NORFOLK VIRGINIA 23511-5230 



4400 

Ser 

N514/6 

374 

08 JUL 
1991 



From: 

To: 



Commander Submarine Force, U.S. Atlantic Fleet 
Commander, Naval Supply Systems Command (Code 0332) 



Sub j : SNAP II SUPPLY AND FINANCIAL MANAGEMENT SYSTEM 

FUNCTIONAL 

ASSESSMENT 



Ref: (a) Commander, Naval Supply Systems 4400 Ser 0332 of 

24 May 1991 

Enel: (1) Type Commander SNAP II SFM Functional Evaluation 

(2) Type Commander SNAP II SFM Functional Needs 
Assessment 

(3) Type Commander SNAP II SFM Reports Critique 

1. In response to reference (a), enclosures (1) through (3) are 
forwarded. Some of the forms in the enclosures were left blank due to 
the ambiguous nature of the application or sub-function description. We 
would be happy to comment if the ambiguities can be clarified. 

2. Our position remains that of supporting and improving the current 
SNAP II software found in SFM, as well as the Maintenance Data Subsystem 
(MDS) , rather than creating entirely new software. Although the current 
software is not without it's problems, we feel that incremental change 
is the only realistic approach to solving them. 

My point of contact is SKCS(SS) E. Bures, Code N514, AUTOVON 
564-6783 or Commercial (804) 444-6781. 



D.N. DOYLE 
By direction 

Copy to: (w/o ends) 

C INCLANTFLT (N4) 

NAVMASSO (01) 

NAVSEA (04-TD) 

NAVSEA ( PMS-331 ) 
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DEPARTMENT OF THE NAVY 

COMMANDER NAVAL SURFACE FORCE 
UNITED STATES PACIFIC FLEET 
SAN DIEGO, CALIFORNIA 92155-5035 



4400 

Ser N7/7469 
15 AUG 199] 



From: Commander, Naval Surface Force, U. S. Pacific Fleet 

To: Commander, Naval Supply Systems Command 

Sub j SNAP II SUPPLY AND FINANCIAL MANAGEMENT SYSTEM FUNCTIONAL 

ASSESSMENT 



Ref: (a) COMNAVSUPSYSCOM ltr 0332 4400 of 24 May 1991 



Enel : 



(1) SNAP II Supply and Financial Management Reports Analysis 

(2) Type Commander SNAP II Supply and Financial Functional 
Evaluation 

(3) Type Commander SNAP II Supply and Financial Functional Needs 
Assessment 

(4) Concept of Operations 



1. Pursuant to agreements made during the April 1991 Functional Policy 
Council, reference (a) provided a matrix of afloat business system 
applications for review. In addition, reference (a) forwarded 
questionnaires in regard to each business application now included in 
the current 5.10 release, for those not now automated in SFM 5.10, and 
with regard to SNAP II Supply and Financial Management Reports. As 
requested by reference (a), enclosures (1), (2), and (3) have been 

completed and are returned. 



2. Enclosures (1), (2), and (3) were reviewed and completed by members 

of COMNAVSURFPAC ' s Supply Maintenance Mobile Training Team (SMTT) , all 
experts in shipboard/staff applications of SNAP II SFM and MDS. SMTT 
comments are reflected in pencil on each questionnaire. Having 
developed their expertise in the shipboard environment, the comments 
provided in pencil on enclosures (I), (2), and (3) are necessarily 

bounded by existing SNAP II SFM/MDS environmental constraints. 



3. Subsequent to SMTT review and comment, the enclosures (2) and (3) 
questionnaires were subjected to a second review at the COMNAVSURFPAC 
management (0-5/0-6) level. The intent of this second review was to 
explore business application development, taking into consideration 
environmental constraints redefined by technological advances including, 
for example, analog and/or digitized data transmission via satellite. 

In such environment, the opportunities for ships becoming Transaction 
Item Reporting (TIR) activities are significant. Enclosure (4) provides 
the applicable concept of operations. Through such advances 
considerable workload can be moved ashore to pierside support activities 
while continuing only those functions aboard ship that directly 
contribute to shipboard combat capability. Those 
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Sub j : SNAP II SUPPLY AND FINANCIAL MANAGEMENT SYSTEM FUNCTIONAL 
ASSESSMENT 

applications which have potential for being moved ashore through the TIR 
concept have been appropriately annotated in red ink for consideration 
in future development. 

4. COMNAVSURFPAC Point of Contact is LT S. Smith, SC, USN, Code 
714/SMTT, A/V 526-5789/commercial . (619) 556-5789 or CAPT R. Gunderson, 

SC, USN, N7 , A/V 577-2410/commercial (619) 437-2410. 



R. H. GUNDERSON 
By direction 

Copy to: 

CINCPACFLT (41) 



2 



59 



TIR CONCEPT OF OPERATIONS 



The concept of operations proposed in paragraph three of the basic 
letter incorporates satellite communications technology to move workload 
ashore and reduce inventory investment afloat. A basic outline of the 
concept is provided as follows: 

- The SNAP II SFM file as it exists aboard ship today will be moved 
ashore to the Pierside Support Activity. The ship will be furnished with c 
automated inventory /location file showing minimal data elements to include 
NSN , Nomenclature, On Hand balance, and location? 

- The ship will transmit transaction item reports via satellite 
communications at scheduled times to the Pierside Support Activity. Data v. 
include receipt and issue transactions, DTO requisitions, and responses to 
specific Pierside Support Activity data inquiry (e . g. , location/count 
inventory directives, etc.) transactions previously transmitted to the shij 
via satellite communications. 

- The Pierside Support Activity will maintain the ship's SNAP II SFM 
data base, generate all financial reports/listings, run levels, generate 
reorders /replenishment requisitions, process ship DTO requisitions into ths 
supply system, and otherwise dialogue with the shore supply and finance 
establishment in resolving issues. The ship will be responsible for issuir 
material from its storerooms and receiving material into its storerooms, ar 
TIR'ing such transactions to the Pierside Support Activity via satellite 
communications. Transactions/adjustments to shipboard inventory /location lj 
will be accomplished by TIR from the Pierside Support Activity via satellit 
communications . 

- Shipboard issues, receipts, and directed inventories would be 
accomplished using barcode scanning equipment, storing all transactions foi 
automatic download to communications equipment and transmission via 
communications satellite. 

Using existing technology, this concept of operations significantly simplil! 
the afloat storekeepers daily workload, reducing it to one of receiving, 
issuing, inventorying as directed, and transmitting data. Workload reductii 
afloat would be used to realign manpower to staff Pierside Support Activiti 
Total visibility of assets afloat would also provide significant opportunit 
for inventory investment savings afloat (e. g., insurance items need no lor 
be stocked in every COSAL but perhaps in only one COSAL of ships operating 
close proximity.) 

While the above addresses the shipboard repair part/general stores SFM 
function, it has equal applicability to the food service/provisions, ships 
store, personnel, and disbursing functions as well as to various Maintenanc 
Data System functions. 
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DEPARTMENT OF THE NAVY 

COMMANDER NAVAL SURFACE FORCE 
UNITED STATES ATLANTIC FLEET 
NORFOLK, VIRGINIA 23511-5215 

4000 

Ser N752/63410 
8 JUL 1991 

From: Commander, Naval Surface Force, U.S. Atlantic Fleet 

To: Commander, Naval Supply Systems Command 

Sub j : SNAP II SUPPLY AND FINANCIAL MANAGEMENT SYSTEM (SFM) 

FUNCTIONAL ASSESSMENT 

Ref: (a) COMNAVSUPSYSCOM ltr 0332 44400 of 24 May 91 

Enel: (1) Type Commander SNAP II SFM Functional Evaluation 

(2) Type Commander SNAP II SFM Functional Needs Assessment 

(3) Type Commander SNAP II SFM Reports Critique 

1. In accordance with reference (a), enclosures (1) through (3) are 
submitted to assist in completing the functional assessment of SNAP 
Material Management Systems for future afloat use. 

2. COMNAVSURFLANT point of contact SKCS(SW) McGourn, N7521, commercial 
(804) 444-5816, AUTOVON 564-5816. 



J. W. FREEMAN, JR. 
By direction 
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DEPARTMENT OF THE NAVY 

COMMANDER SUBMARINE FORCE 
UNITED STATES PACIFIC FLEET 
PEARL HARBOR, HI 96860-6550 



4400 

Ser 5121/005008 
24 JUL 1991 

From: Commander Submarine Force, U.S. Pacific Fleet 

To: Commander, Naval Supply Systems Command (033) 

Sub j : SNAP II SUPPLY AND FINANCIAL MANAGEMENT SYSTEM 

FUNCTIONAL ASSESSMENT 

Ref: (a) COMNAVSUPSYSCOM ltr Ser 0332-4400 of 24 May 91 

Enel: (1) SNAP II Supply and Financial Management Reports 

Analysis 

(2) Type Commander SNAP II Supply and Financial Functional Evalua 

1. The functional assessment enclosed in reference (a) has been 
reviewed and is returned with requested responses as enclosures (1) and 
(2) . 

2. COMSUBPAC point of contact is LT Dana Ivey (Code 5121) who may be 
reached at A/V 471-8111 or COML (808) 471-0464/9034. 



D. R. LENGKEEK 
By direction 
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DEPARTMENT OF THE NAVY 

COMMANDER NAVAL SURFACE FORCE 
UNITED STATES PACIFIC FLEET 
SAN DIEGO, CALIFORNIA 92155-5035 



4400 

Ser 713/7059 
30 JUL 1991 

From: Commander, Naval Surface Force, U.S. Pacific Fleet 

To: Commander, Naval Supply Systems Command 

Sub j : SUADPS RELEASE 3 FUNCTIONAL ASSESSMENT 

Ref: (a) COMNAVSUPSYSCOM ltr 0332 4400 of 24 May 91 

Enel: (1) Type Commander SUADPS Functional Evaluation 

(2) Type Commander SUADPS Functional Needs Assessment 

(3) Type Commander SUADPS Reports Critique 

1. The SUADPS Functional Evaluations, Needs Assessments, and Report 
Critiques forwarded by reference (a) were reviewed in depth by five 
COMNAVSURFPAC evaluators, representing over 70 years of SUADPS 
experience. Enclosures (1) through (3) are a consolidated input, based 
on the evaluators' review. 

2. In general, the evaluators found this functional assessment process 
to be difficult, at best. Also, the evaluators found that a significant 
number of applications which are identified as currently being available 
in SUADPS are, in fact, not available. The reverse situation was also 
found to exist. The fact that our evaluators could not reach the same 
conclusion as NAVMASSO as to whether or not an application is available 
in SUADPS, supports our finding that it is difficult to interpret the 
meaning of the functions and applications. In short, any conclusions 
drawn from this study must be viewed with caution. The following 

c omment s apply: 

a. Numerous business functions and/or applications could not be 
interpreted as to their actual meaning; 

b. Functions and applications as stated, often duplicated or 
overlapped other applications; and 

c. Many of the business applications "considered necessary" for modern 
afloat supply operations are defined in terms of current SUADPS terminology 
and are questionable "required" applications. (Example: Validation Tables, 
Local Constants, Counters.) These applications are required in our current 
system design, but may be unnecessary in a redesigned system with different 
goals and objectives. 

3. Interestingly, the evaluation shows that individually, many of the 
SUADPS applications work as advertised. But as evidenced from our 
operational experience, there are numerous problems when these inter-related 
applications are combined. There is no synergy in the current process. 

This is due in part to the complexity of Navy Stock Fund financial reporting 
requirements and the computer programming required in SUADPS to support this 
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effort. This, coupled with the level of knowledge required to understand 
and manage this system are the root of our problems. We must simplify, 
simplify, simplify! 

As stated numerous times in the past, to simplify the process we must 
use today's technology and link afloat data bases with shore-based systems 
to utilize the synergistic effect of shared information. No one is debatin 
the fact that there are obviously good ideas in SUADPS, OMMS, IMMS/MRMS, an 
SNAP II SFM/MDS, along with other shipboard AIS's. But, as agreed upon at 
the January 1987 MMAIP, a zero based redesign is the only way we can get 
away from making an overly complex system even more complex by applying 
bandaids to continually correct system deficiencies.' Acknowledging that we 
have already embarked on one grandiose zero based redesign effort which 
failed because of it's own weight and that the chance of starting another 
zero based redesign to achieve an optimal solution is unlikely, than we hav 
to do something to help people better understand the system in place. To a 
this, we ought to capitalize on the effort that has already gone into the 
zero based redesign and list the information that people have already 
identified as being the information they want to derive. Then a matrix can 
be constructed showing the desired information product on the left and the 
existing business functions on the right which can be utilized to provide 
the desired information. Business functions that do not contribute to a 
specific desired information product should be candidates for elimination. 
The resulting business functions can then be evaluated to see if they can t 
simplified or if the burden of using them exceeds the value of the 
information derived. In this way, the business functions can be evaluated 
in context of the role they play in the overall system. To try to evaluate 
the business functions as stand alone entities is confusing to all concerns 
and can lead to a lack of coordination and agreement on how to interpret th 
questions and therefore to a data base of answers which may be seriously 
misinterpreted. 

5. COMNAVSURFPAC point of contact is CDR C. A. Toledo, SC, USN, Code 713, 
or CAPT G. Locke, USMC, Code 713A at AUTOVON 526-5748 or commercial (619) 
556-5748. 



K. W. LIBBY 
By direction 



2 
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UNITED STATES MARINE CORPS 

2d MARINE AIRCRAFT WING, FMF , ATLANTIC 
MARINE CORPS AIR STATION 
CHERRY POINT, NORTH CAROLINA 28533-6001 

IN REPLY REFER 
TO 

4400 
ALD/srf 
15 Jul 1991 



From: Commanding General, Second Marine Aircraft Wing 

To: Command-, Naval Supply System Command (0332), 

Washington, DC 20376-5000 

Sub j : SUADPS RELEASE 3 FUNCTIONAL ASSESSMENT RESPONSE 

Ref: Commander, Naval Supply Systems Command, 0332 over 4400 

dated 24 May 1551 

Enel: (1) Type Commander SUADPS Functional Evaluation 

(2) Type Commander SUADPS Functional Needs Assessment 

(3) Type Commander SUADPS Reports Critique 

1. As requested, the enclosures have been reviewed and annotated. 

2. Please note that this package was reviewed from a Marine aviation 
logistics perspective which includes both NALCOMIS and SUADPS-RT 
processing systems. The on-line help function in NALCOMIS is a very 
valuable tool. This function does not exist in SUADPS-RT but should be 
implemented in any follow-on system. 

3. 2d MAW POC: CWO-2 S. Foster, ALD-L, Av: 582-5111/3933. 



M. C. SKIPPER 
By direction 



Copy to: 

CMC (ASL-32 ) 
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DEPARTMENT OF THE NAVY 

COMMANDER NAVA1 AIR FORCE 
UNITED STATES PACIFIC FLEET 
NAVAL AIR STATION, NORTH ISLAND 
SAN DIEGO, CALIFORNIA 92135-5100 



4400 

Ser 453/6561 
06 AUG 1991 

From: Commander Naval Air Force, U.S. Pacific Fleet 

To: Commander, Naval Supply Systems Command 

Sub j : SUADPS RELEASE 3 FUNCTIONAL ASSESSMENT 

Ref: (a) COMNAVSUPSYSCOM ltr 0332 4400 of 24 May 91 

Enel: (1) Type Commander SUADPS Functional Evaluation 

(2) Type Commander SUADPS Functional Needs Assessment 

(3) Type Commander SUADPS Reports Critique 

1. The SUADPS products forwarded by reference (a) have been reviewed 
and are being returned as enclosures (I) through (3). The following 
comments apply: 



a. Many of the business functions and/or applications were not 
understood by anyone on this staff; the package was reviewed by two 
Senior and two Master Chief Petty Officers, a GS-12 Financial Analyst, a 
Lieutenant (former stock control officer) and two former SUADPS 
experienced Limited Duty Officers, one was a Lieutenant Commander with 
31 years experience and the second was a Lieutenant with 27 years 
experience. The difficulty of developing a comprehensive and explicit 
functional evaluation for a baseline review of our current business 
applications is appreciated, however the one or two word descriptions 
provided for the function, sub-function and application titles were much 
too general in nature resulting in a lot of confusion about what 
function actually was being analyzed. 

b. Functions and applications were frequently either duplicated or 
contained within other applications. 



c. Many of the applications do not appear to be related to SUADPS 
Release 3 or any other management system of the future which will replace 
Release 3 (e.g. SAMS, ADMIN and Ship's Store Returns). The fact that thes 
applications are performed aboard ships does not make them viable candidate 
for inclusion in a mainframe computer Supply and Financial Management Systi 
of the future cannot and should not be an all inclusive AIS containing evei 
conceivable function performed aboard ships. Not only should some of those 
functions be properly accomplished manually, but also those functions thatii 
stand alone and can be performed on a micro-computer system should remain i 
micro computers. 

2. The objective of any future inventory /financial management system show 
be to enable the shipboard storekeeper to concentrate his efforts on accur:; 
receipt, issue and inventory 
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control procedures and not have to worry whether the appropriation data for 
another ship he has just made a transfer to is contained in validation tables. 
Those financial applications can and should be performed ashore with existing 
technology used to communicate to the shore facility what material 
transactions have occurred. 

3. The tremendous effort put into developing this baseline review is obvious; 
the validity of the results are certain to be suspect given the ambiguities of 
the functional descriptions. Informal conversations with COMNAVSURFPAC and 
COMNAVAIRLANT have expressed the same concern and frustration of attempting to 
design software by mail. A working level (one or two experts per TYCOM and 
CDA) conference to review the results and clear up any lingering concerns to 
be the next step in this process. 

4. COMNAVAIRPAC point of contact is CDR R. A. Boyd, Code 45 or LT 

E. S. Walters, Code 453 at AUTOVON 735-1020 or Commercial (619) 545-1020. 



R. A. BOYD 
By direction 
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DEPARTMENT OF THE NAVY 

COMMANDER SUBMARINE FORCE 
U.S, ATLANTIC FLEET 
NORFOLK, VIRGINIA 23511-5230 



4400 

Ser N531/2153 
16 AUG 1991 

From: Commander Submarine Force, U.S. Atlantic Fleet Commander, 

To: Commander, Naval Supply Systems Command (SUP 033) 

Subj : SUADPS RELEASE 3 FUNCTIONAL ASSESSMENT 

Ref: (a) NAVSUP ltr Ser 0332/4400 of 24 May 91 

Enel: (1) Type Commander SUADPS Functional Evaluation 

(2) Type Commander SUADPS Functional Needs Assessment 

(3) Type Commander SUADPS Reports Critique 

1. As requested by reference (a), enclosures (1) through (3) are 
forwarded. 

2. Request COMSUBLANT be provided with summary results of the Type 
Commanders SUADPS Functional Assessment no later than 30 September 1991. 



T. 0. DUFFEY 
By direction 
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DEPARTMENT OF THE NAVY 
COMMANDER SUBMARINE FORCE 
UNITED STATES PACIFIC FLEET 
PEARL HARBOR, HI 96860-6550 



4400 

Ser 5113/004436 
27 JUN 1991 

From: Commander Submarine Force, U.S. Pacific Fleet 

To: Commander, Naval Supply Systems Command 

Subj : SUADPS RELEASE 3 FUNCTIONAL ASSESSMENT 

Ref: (a) COMNAVSUPSYSCOM ltr Ser 0332-4400 of 24 May 91 

Enel: (1) Applications Found in Various Afloat Business Systems 

Questionnaires and Type Commander SUADPS Functional Evaluations 

1. The functional assessment enclosed in reference (a) has been 
reviewed and is returned as enclosure (1). 

2. COMSUBPAC point of contact is LT Jim Barnard (Code 5113), who may 
be reached at A/V 471-8111 or COML (808) 471-0464/474-5538. 



D. R. LENGKEEK 
By direction 
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DEPARTMENT OF THE NAVY 



COMMANDER NAVAL SURFACE FORCE 
UNITED STATES ATLANTIC FLEET 
NORFOLK, VIRGINIA 23511-5215 



4400 

Ser N7 2/09579 
8 AUG 1991 

From: Commander, Naval Surface Force, U.S. Atlantic Fleet 

To: Commander, Naval Supply Systems Command (Code 0332) 

Subj : SUADPS-RT REL 3.0 FUNCTIONAL ASSESSMENT 

Ref: (a) COMNAVSUPSYSCOM 0332 4400 of 24 May 91 

Enel: (I) Response Matrix 

(2) SUADPS Functional Evaluation Work Sheets 

(3) SUADPS Functional Needs Assessment Work Sheets 

(4) SUADPS Reports Critique 

1. As requested by reference (a), enclosures (1) through (4) are 
forwarded as input to the, ' comprehensive evaluation of SUADPS. 

2. The Response Matrix, enclosure (1), is provided as a summary sheet 

of responses to key questions as viewed from the TYCOM'S perspective. 
Note that the column addressed as: (1) Non-applicable (N/A) contains 

responses to functionality not intended for SUADPS processing and (2) 
Insufficient Information contains responses to functionality that lacked 
sufficient descriptive information to clearly determine its intended 
purpose or processing goals. 

3. My point of contact for further information is LT D. Lendle (N723), 
AUTOVON 564-5882 or commercial (804) 444-5882. FAX number is (804) 445- 
2236. 



J. E. COOK 
By direction 
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ENCLOSURE ( 1 ) 



CNSL RESPONSE MATRIX 



(1) TYCOM FUNCTIONAL EVALUATION; 
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